Korrekturlesen: Praxisteil

bericht/batch/bat-installation.tex

@@ -8,7 +8,7 @@ Dazu richteten wir den empfohlenen
 dem Head-Node erstellten Schlüssel auf die anderen Nodes
 (\emph{/etc/munge/munge.key}).
 
-SLURM setzt für die Authentifizierung voraus, das der in der Konfiguration
+SLURM setzt für die Authentifizierung voraus, dass der in der Konfiguration
 festgelegten Nutzer auf allen Systemen die gleiche UID besitzt:
 
   \shellcmd{sudo usermod -u 992 slurm}

bericht/batch/bat-konfiguration.tex

@@ -1,12 +1,13 @@
 \subsection{Konfiguration}
 
-Die Konfiguration der Queues (in SLURM \texttt{Partitions} genannt) erfolgt über die
+Die Konfiguration der Queues (in SLURM \texttt{Partitions} genannt) erfolgt über
-Konfigurationsdateien im Ordner \emph{/etc/slurm/} (auch zu finden in \emph{aufgabe5.2/slurm}).
+die Konfigurationsdateien im Ordner \emph{/etc/slurm/} (auch zu finden in
-Die Prioritäten wurden in folgender Reihenfolge absteigend vergeben: benchmark, express, small, long
+\emph{aufgabe5.2/slurm}).  Die Prioritäten wurden in folgender Reihenfolge
-Die \texttt{benchmark}-Partition bekam die größte Priorität, so das Jobs aus anderen
+absteigend vergeben: benchmark, express, small, long. Die
-Queues angehalten werden. Die anderen Queues wurden umgekehrt proportional zur Zeitdauer
+\texttt{benchmark}-Partition bekam die größte Priorität, so das Jobs aus anderen
-priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs, die
+Queues angehalten werden. Die anderen Queues wurden umgekehrt proportional zur
-weniger Zeit benötigen, den richtige Queue zu zu ordnen.
+Zeitdauer priorisiert. Dadurch werden Nutzer des Batchsystems dazu bewegt Jobs,
+die weniger Zeit benötigen, der richtige Queue zu zuordnen.
 
 Zusätzlich zur Verwaltung der Cores haben wir SLURM für die Verwaltung der GPUs
 konfiguriert. Hierfür haben wir auf die Erweiterung \emph{GRES} zurück gegriffen. Die

bericht/batch/bat-maui.tex

@@ -1,9 +1,8 @@
 \subsection{Zusatzaufgabe: Maui}
 
 Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen
-eigenen Scheduler mitbringt und Maui äußerst schwierig einzurichten zu sein
+eigenen Scheduler mitbringt und Maui schwierig einzurichten zu sein scheint, so
-scheint, so dass selbst die SLURM-Entwickler hierzu keine Dokumentation
+dass selbst die SLURM-Entwickler hierzu keine Dokumentation anbieten:
-anbieten:
 
 \epigraph{Maui configuration is quite complicated and is really beyond the scope
 of any documents we could supply with

bericht/bench/bench-imb.tex

@@ -1,6 +1,6 @@
 \subsection{Intel MPI Benchmark (IMB)}
 
-Zur Messung der Kommunikationsleistung wurden die MPI-Test Ping-Pong, Barrier, Allreduce und Alltoall mit variierenden Nachrichtengrößen durchgeführt.
+Zur Messung der Kommunikationsleistung wurden die MPI-Tests Ping-Pong, Barrier, Allreduce und Alltoall mit variierenden Nachrichtengrößen durchgeführt.
 
 \subsubsection{Ping-Pong}
 

bericht/bench/bench-iozone.tex

@@ -27,7 +27,8 @@ Testaufruf:
 
 \shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
 
-Der Parameter \emph{-+q 1} sorgt für einen Verzögerung zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
+Der Parameter \emph{-+q 1} sorgt für eine Verzögerung zwischen den einzelnen
+Tests. Ist dieser Parameter nicht gesetzt, läuft der Benchmark fehlerhaft durch.\\
 
 \subsubsection{Auswertung}
 
@@ -36,13 +37,13 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
 \shellcmd{hdparm -t /dev/sda}
 
 Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
-der Leistungsfähig der Festplatte entsprechen.
+der Leistungsfähigkeit der Festplatte entsprechen.
 
 GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
 gleich auf. Die Schreibgeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
 liegt damit weit hinter NFS. Dies lässt sich im Wesentlichen darauf
 zurückführen, dass GlusterFS ein FUSE-Dateisystem ist und es deshalb bei jeder
-Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
+Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, um die Daten
-einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt
+auf den anderen Nodes verteilt schreiben zu können. Zusätzlich stellen hier
-schreiben zu können.  Zusätzlich stellen hier also auch die Atom-Prozessoren
+also auch die Atom-Prozessoren durch ihre begrenze Leistungsfähigkeit einen
-durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar.
+limitierenden Faktor dar.

bericht/bs/bs-git.tex

@@ -28,7 +28,7 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen:
 
 \subsubsection{Etckeeper}
 
-Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu
+Um die Konfiguration in \emph{/etc} versionierbar und damit nachvollziehbar zu
 machen installierten wir \emph{Etckeeper}:
 
 \shellcmd{yaourt -S etckeeper \&\& sudo etckeeper init}
@@ -65,8 +65,8 @@ ein. Im Unterschied zu herkömmlichen Syslog-Varianten speichert Journald in
 einem eigenen Binärformat ab. Dieses Dateiformat eignet sich aus
 offensichtlichen Gründen nicht um mithilfe von git verwaltet zu werden. Deswegen
 haben wir zusätzlich \emph{Syslog-ng} installiert und \emph{Journald} so
-konfiguriert, das es ebenfalls in das syslog schreibt (siehe
+konfiguriert, das es ebenfalls in das Syslog schreibt (siehe
-\emph{aufgabe2.4/journald.conf}). Für tägliche commits haben wir hierfür das
+\emph{aufgabe2.4/journald.conf}). 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 lädt die Log-Dateien
 in das logs-Repository hoch. Es ist als Submodule im Verzeichnis \emph{logs} im

bericht/bs/bs-pdsh.tex

@@ -13,7 +13,7 @@ unserem Fall Head-Node und Compute-Nodes) greift \emph{Pdsh} auf die
 Gruppenbeschreibungsdatei \texttt{ /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 \emph{PDS\_RCMD\_TYPE} auf
+beim Verbinden verwendet, muss die Umgebungsvariable \emph{PDS\_RCMD\_TYPE} auf
 den Wert ``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

@@ -23,8 +23,8 @@ den SSH-Port 22 beschränkt.
 
 \subsubsection{Absicherung für externen Zugriff}
 
-Um den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
+Um das Cluster gegen den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
-Möglichkeiten
+Möglichkeiten:
 
 \begin{enumerate}
   \item den externen SSH-Port auf einen anderen Port als 22 legen, so dass

bericht/bs/bs.tex

@@ -29,10 +29,10 @@ Wir sind bei der Installation grundlegend nach der Anleitung im \href{https://wi
 
 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 \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 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 der Bootloader \emph{GRUB} installiert und konfiguriert.
 
-Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische
+Nach dem erfolgreichen Reboot haben wir das Netzwerk auf eine statische
-IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Head-Node
+IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl der Head-Node
 als auch der erste Compute-Node grundsätzlich einsatzfähig.
 
 \subsubsection{Netzwerk-Konfiguration}
@@ -43,11 +43,13 @@ 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 Head-Node mussten wir noch mittels \emph{iptables} das \texttt{
+Auf dem Head-Node mussten wir noch mittels \emph{iptables} das
-MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf
+\texttt{MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der
-dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
+\emph{nat}-Tabelle auf dem \emph{eth0}-Interface setzen (siehe
-\emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1}
+\emph{aufgabe2.3/iptables.rules}) und mit \emph{sysctl} (\emph{/etc/sysctl.d})
-(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Compute-Nodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
+die Option \emph{net.ipv4.ip\_forward = 1} (siehe
+\emph{aufgabe2.2/10-ip-forward-conf}) freischalten, so dass die Compute-Nodes auch
+auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
 
 \input{bs/bs-ssh}
 

bericht/burnin.tex

@@ -5,7 +5,7 @@
 \label{sub:munin}
 
 Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
-\texttt{Munin} eingerichtet. Munit besteht aus einem Masterprozess, welches
+\texttt{Munin} eingerichtet. Munin 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 \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den

bericht/prov/prov-backup.tex

@@ -5,10 +5,10 @@ Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gr
 
 \begin{itemize}
   \item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu sichernden System.
-    Dies hat den Vorteil, dass andere Nutzer diese einsehen können und
+    Dies hat den Vorteil, dass Nutzer ihre eigenen Daten einsehen können und
     selbständig Dateien wiederherstellen können.
   \item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die
-    sich zum alten Backup sich nicht geändert haben durch Hardlinks in das neue
+    sich zum alten Backup sich nicht geändert haben, durch Hardlinks in das neue
     Backup verlinkt.
   \item Programme wie duplicity speichern die Differenz zum alten Stand als
     Delta ab. Diese Kette von Revisionen müssen beim Wiedereinspielen angewendet

bericht/prov/prov-compiler.tex

@@ -23,7 +23,7 @@ finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
 \subsubsection{Intel Compiler Suite}
 \label{ssub:intel_compiler_suite}
 
-Wir installierten die Intel Compiler Suite in der Version 2013\_sp1.1.106
+Wir installierten die Intel Compiler Suite in der Version 2013\_sp1.1.106.
 Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/icc} zu
 finden.
 

bericht/prov/prov-provisioning.tex

@@ -5,12 +5,11 @@
 
 \begin{sloppypar}
 
-Für die Provisionierung wurde Clonezilla verwendet. Wir haben uns für dieses
+Für die Provisionierung wurde Clonezilla verwendet. Bei einem Netzwerk-Boot
-Verfahren entschieden. Bei einem Netzwerk-Boot beispielsweise, bei dem das
+beispielsweise, bei dem das gesamte Dateisystem per NFS eingebunden wird, wäre
-gesamte Dateisystem per NFS eingebunden wird, wäre in unserem Fall ineffektiv,
+in unserem Fall ineffektiv, da auf den Festplatten der Compute-Nodes genügend
-da auf den Festplatten der Compute-Nodes genügend Speicher für das
+Speicher für das Betriebssystem vorhanden ist und bei jedem Zugriff auf das
-Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen
+Dateisystem unnötigen Latenzen entstehen würden.
-Latenzen entstehen würden.
 
 Um Clonezilla auf den Compute-Nodes zu booten, haben wir den
 \emph{in.tftpd}-Server installiert und das Service-File für \emph{Systemd}
@@ -19,7 +18,8 @@ Konfiguration des DHCP-Servers so angepasst, dass nun jede Compute-Node eine
 eigene Konfigurationsdatei in \emph{/etc/dhcpd.d/} hat, die jeweils von
 \emph{/etc/dhcpd.d/all} inkludiert wird.
 
-Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Compute-Nodes verwaltet werden können. Mit
+Um die Compute-Nodes zu verwalten, haben wir das Script \emph{cluster}
+geschrieben. Mit dem Befehl
 \begin{lstlisting}
 cluster add <HOSTNAME> <IP> <MAC>
 \end{lstlisting}
@@ -29,7 +29,7 @@ cluster set-<MODE> <HOSTNAME>
 \end{lstlisting}
 kann der Modus für den nächsten Boot des Nodes festgelegt werden. Hier kann
 zwischen \emph{local} (Boot von lokaler Festplatte), \emph{live} (Boot in das
-Clonezilla Image), \emph{clone} (Clonen nach Boot) und \emph{restore} (Image
+Clonezilla Image), \emph{clone} (Klonen nach Boot) und \emph{restore} (Image
 laden nach Boot) gewechselt werden.
 
 Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{pxelinux} unter
@@ -46,38 +46,38 @@ Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}.
 
 \begin{sloppypar}
 
-Um den Clone-Vorgang zu starten, führten wir nun mit dem Befehl \emph{sudo
+Um den Klonvorgang zu starten, führten wir den Befehl \texttt{sudo cluster
-cluster set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla
+set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla Live
-Live Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es
+Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es aus.
-aus. In diesem Script haben wir alle nötigen Befehle eingetragen, um das Clonen
+In diesem Script haben wir alle nötigen Befehle eingetragen, um das Klonen
 vorzubereiten und zu starten (siehe \emph{aufgabe4.4/clone.sh}). Dazu wird per
 NFS das \emph{/cluster}-Verzeichnis des Head-Nodes eingebunden und dort im
 Unterverzeichnis \emph{images} das Image der Festplatte abgelegt. Geklont werden
-nur die \emph{/}- und die \emph{/boot}-Partition.
+die \emph{Root}- und die \emph{Boot}-Partition.
 
 Zum Wiederherstellen des Images wird mit \emph{sudo cluster set-restore
 <HOSTNAME>} wieder der entsprechende Boot-Modus gesetzt und der Node
-neu gestartet Dort wird nun ein anderes Script vom Head-Node geholt (siehe \emph{
+neu gestartet. Dort wird nun ein anderes Script vom Head-Node 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 das Dateisystemformat \emph{ext4} nicht als solches
-erkannt hat. Es fiel auf das generische Programm \emph{partclone.dd} zurück,
+erkannt hat, fiel auf das generische Programm \emph{partclone.dd} zurück,
 welches allerdings sehr langsam ist, weil es die komplette Partition klont und
 freie Blöcke nicht überspringt. Deswegen haben wir zwei kleine Wrapper-Scripts
 geschrieben.Diese Skripte verwenden stattdessen das schnellere
 \emph{partclone.ext4} (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
+Da in unserem Cluster gemischte Boards (Intel und Zotac) sind, mussten wir
 anschließend außerdem noch das Ziel-Root-Verzeichnis mounten und dort mit Befehl
 \emph{mkinitcpio -p linux} ein neue Init-Ramdisk erstellen lassen, welches die
-entsprechenden Treiber für Bootvorgang enthält.
+entsprechenden Treiber für den Bootvorgang enthält.
 
 Um die automatische Umbenennung der Netzwerk-Interfaces vorzubeugen, haben wir
 außerdem einen Symlink \emph{/etc/udev/rules.d/80-net-name-slot.rules ->
-/dev/null} erstellt. Dadurch wird verhindert, dass Ethernet-Interface nicht nach
+/dev/null} erstellt. Dadurch wird verhindert, dass das Ethernet-Interface nicht nach
-dem neuen Schema enpXsY sondern fest den Namen eth0 erhalten.
+dem neuen Schema enpXsY, sondern fest den Namen eth0 erhält.
 
 \end{sloppypar}

bericht/sv/sv-dhcp_dns.tex

@@ -21,9 +21,9 @@ host zotac<X> {
 \end{lstlisting}
 
 Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte
-IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig
+IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen und gleichzeitig ihren
-ihren Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über
+Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über den
-den lokalen DNS-Server auf.
+lokalen DNS-Server auf.
 
 Zusätzlich haben wir das bereits in der Installation enthaltene
 \emph{Systemd}-Service-File entsprechend so angepasst, dass beim Starten und
@@ -40,7 +40,7 @@ Wobei \emph{eth1} der Name des Interface ist, das am internen LAN angeschlossen
 
 \begin{sloppypar}
 
-Als Client verwenden wir \emph{Dhcpcd}.
+Als Client verwenden wir den \emph{Dhcpcd}.
 
 Um den Hostnamen per DHCP zu setzen, mussten wir in
 \emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe
@@ -63,12 +63,12 @@ ersetzt, damit der bezogene Hostname automatisch persistent (\emph{/etc/hostname
 \subsection{DNS}
 \label{ssub:dns}
 
-Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \emph{Bind} installiert und
+Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \emph{Bind}
-eingerichtet. Die Konfiguration ist in \emph{aufgabe3.2/named.conf} zu finden.
+installiert und eingerichtet. Die Konfiguration ist in
-Für das Auflösen der Hostnames haben wir die Domaine zotac
+\emph{aufgabe3.2/named.conf} zu finden.  Für das Auflösen der Hostnames haben
-\emph{aufgabe3.2/zotac.zone} angelegt und ein Zonefile für die
+wir die Domaine zotac (\emph{aufgabe3.2/zotac.zone}) angelegt und ein Zonefile
-Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}. Schließlich
+für die Reverse-DNS-Auflösung \emph{aufgabe3.2/0.20.10.in-appr.arpa}.
-musste noch die /etc/resolv.conf angepasst werden, so dass der eingerichtete
+Schließlich musste noch die /etc/resolv.conf angepasst werden, so dass der
-Server auch von der Head-Node zur Adress-Auflösung benutzt wird
+eingerichtete Server auch von der Head-Node zur Adress-Auflösung benutzt wird
 (\emph{aufgabe3.2/resolv.conf}). Die Nodes bekommen die DNS-Einstellungen per
 DHCP zugewiesen.

bericht/sv/sv-filesystems.tex

@@ -5,30 +5,30 @@
 \label{ssub:nfs}
 
 Wir haben uns für das NFS-Dateisystem entschieden. Dieses ermöglicht
-ressourcensparend Verzeichnisse zwischen der Head-Node und den Compute-Nodes zu
+ressourcensparend Verzeichnisse zwischen dem Head-Node und den Compute-Nodes zu
 teilen.
 
 Unter Archlinux ist der NFS-Server im Paket \emph{nfs-utils} zu finden.
-Um NFS zu exportieren, starteten wir auf dem Head-Node den rpc-mountd.service.
+Um NFS zu exportieren, starteten wir auf dem Head-Node den \emph{RPC-Mountd}.
 Das ID-Mapping der symbolischen Benutzer und Gruppen auf die User- und Group-IDs
-übernimmt in unserem Fall der LDAP-Dienst (\ref{sub:ldap}). Auf den
+übernimmt in unserem Fall der LDAP-Dienst (\ref{sub:ldap}). Auf dem
 Compute-Node wurde jeweils ein Eintrag für die Verzeichnisse \emph{home} und
 \emph{cluster} in der Datei \emph{/etc/fstab} angelegt. (siehe \emph{aufgabe3.1/fstab}).
 
 \subsubsection{Verteiltes Dateisystem}
 \label{ssub:verteiltes_dateisystem}
 
-Als Dateisystem haben wir uns für GlusterFS entschieden. Im Vergleich zu anderen
+Wir haben uns für GlusterFS als verteiltes Dateisystem entschieden. Im Vergleich
-verteilten Dateisystemen besitzt GlusterFS keine zentrale Metadaten-Server.
+zu anderen verteilten Dateisystemen besitzt GlusterFS keine zentrale
-Stattdessen verteilt es die Metadaten durch eine Netzwerktechnologie, die sich
+Metadaten-Server. Stattdessen verteilt es die Metadaten durch eine
-Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und
+Netzwerktechnologie, die sich Elastic-Hashing nennt. Dieser verteilte Ansatz
-Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum
+verbessert die Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre,
-Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere
+der Metadatenserver häufig zum Flaschenhals wird. Das Dateisystem lässt sich im
-Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden,
+laufenden Betrieb um weitere Nodes erweitern. GlusterFS kann auf beliebige
-was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzige
+Dateisysteme aufgesetzt werden, was die Wiederherstellung im Falle eines
-Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von FUSE im
+Absturzes vereinfacht. Der einzige Nachteil, der uns aufgefallen ist, ist das
-User-Space implementiert ist, was potentiell langsamer als eine entsprechende
+GlusterFS auf Basis von FUSE im User-Space implementiert ist, was potentiell
-Kernel-Implementierung ist.
+langsamer als eine entsprechende Kernel-Implementierung ist.
 
 Als Dateisystem für GlusterFS wird XFS empfohlen. Dafür haben wir eine 50GB
 Partition angelegt, diese mit Befehl:
@@ -54,7 +54,7 @@ Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der \emph{aufgab
 zotac0:/gv0 /fastfs glusterfs defaults 0 0
 \end{center}
 
-Um die Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}:
+Um den Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}:
 
 \shellcmd{dd bs=1M count=512 if=/dev/zero of=/path/to/file conv=fdatasync}
 
@@ -71,7 +71,7 @@ diesem vor jedem Durchlauf geleert:
 \shellcmd{sync; echo 3 | tee /proc/sys/vm/drop\_caches}
 
 Die Tests wurden auf dem Host zotac1 ausgeführt, wobei {\emph Lokal}, dem
-lokalen Ext4-Dateisystem entspricht, NFS dem gemounten NFS von zotac0 und
+lokalen Ext4-Dateisystem entspricht, NFS, dem gemounten NFS von zotac0 und
 GlusterFS, dem Dateisystem im Pfad \emph{/fastfs} entspricht. Die Rohdaten
 befinden sich in \emph{aufgabe3.3/benchmark.txt}
 

bericht/sv/sv-iptables.tex

@@ -7,7 +7,7 @@ Filterregeln aus der Datei \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 Brute-Force-Angriffe wird der Dienst
+\emph{ICMP} erlaubt. Zur Absicherung gegen Brute-Force-Angriffe wird der Dienst
 \emph{SSH-Guard} verwendet. Für SSH-Guard haben wir eine eigene Chain
 mit dem Namen \emph{sshguard} in der \emph{iptables.rules} eingetragen. Alle Zugriffe
 auf Port 22 werden durch diese Chain gefiltert. Erfolgen in kurzer Zeit zu viele

bericht/sv/sv-ldap.tex

@@ -25,9 +25,9 @@ eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
 \subsubsection{Absicherung und Zugriff}
 
 Wir haben die Zugriffsrechte so konfiguriert, dass jeder Benutzer sein eigenes
-Passwort ändern, aber niemand das Passwort auslesen darf. Dieses wird nur für
+Passwort ändern kann, aber niemand das Passwort auslesen darf. Dieses wird nur
-zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von allen
+für zur Authentifizierung abgerufen werden. Alle anderen Attribute dürfen von
-Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf})
+allen Users gelesen werden. (siehe \emph{aufgabe3.5/slapd.conf})
 
 Um auf den Verzeichnisdienst zugreifen zu können, haben wir eine Datei
 \emph{/etc/ldap.secret} mit dem Passwort für den Administrator-Account in LDAP
@@ -72,7 +72,7 @@ folgende Dateien geändert (siehe Dateien in \emph{aufgabe3.5/pam.d}):
 \begin{lstlisting}
 	password  sufficient  pam_ldap.so
 \end{lstlisting}
-	
+
 \end{itemize}
 
 \begin{sloppypar}
@@ -80,12 +80,15 @@ 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 \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.
+\emph{first-login} (siehe \emph{aufgabe3.5/first-login}) ausgeführt; das Script
+wurde aus Aufgabe 2.3 übernommen und für die Einbindung in PAM angepasst. Es
+wird 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
+für SSH, kopiert eine Beispiel-SSH-Konfiguration in dessen 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.
+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}

bericht/sv/sv-ntp.tex

@@ -6,4 +6,4 @@ Auf dem Head-Node wurde der NTP-Server der TU-Dresden mit der Domain \emph{time.
 restrict 10.20.0.0 mask 255.255.255.0 nomodify notrap nopeer
 \end{lstlisting}
 
-Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingetragen.
+Auf dem Compute-Node wurde \emph{zotac0} als Zeitserver eingestellt.