Mic92
/
ltcp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

hunspell-check

This commit is contained in:
Jörg Thalheim 2014-04-05 17:35:12 +02:00
parent 95e291e509
commit 9acc0bd116
18 changed files with 55 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bericht/batch/bat-installation.tex
View File

@ -9,7 +9,7 @@ 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
festgelege Nutzer auf allen Systemen die gleiche UID besitzt:
festgelegten Nutzer auf allen Systemen die gleiche UID besitzt:
\shellcmd{sudo usermod -u 992 slurm}

6
bericht/batch/bat-konfiguration.tex
View File

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

6
bericht/bench/bench-hpl.tex
View File

@ -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 \emph{allnodes} sind die Hostnames der Computenodes hinterlegt.
In der Datei \emph{allnodes} sind die Hostnames der Compute-Nodes hinterlegt.
Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit folgender Konfiguration erreicht:
\begin{lstlisting}
@ -15,7 +15,7 @@ Beim Basislauf wurde ein maximaler Wert von $3,842 \cdot 10^{-4}$ GFlops mit fol
WR00L2L2 35 4 1 4
\end{lstlisting}
Der optimierte Lauf mit der Standard BLAS-Library des Systems mit der Konfiguration:
Der optimierte Lauf mit der Standard-BLAS-Bibliothek des Systems mit der Konfiguration:
\begin{lstlisting}
T/V N NB P Q
@ -36,7 +36,7 @@ einen Wert von {\bf 4,076 GFlops}.
\subsubsection{Auswertung}
Verglichen mit der theoretischen Floating Point Peak Performance von: \\ $1,6$
Verglichen mit der theoretischen Floating-Point-Peak-Performance von: \\ $1,6$
GHz $\cdot 2$ CPU-Kerne pro Prozessor $\cdot 2$ Instruktion pro Takt $\cdot 4$
CPUs $ = 25,6$ GFlops \\ erreichten wir also ca. 16 \% der maximal möglichen
Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler

10
bericht/bench/bench-iozone.tex
View File

@ -27,7 +27,7 @@ Testaufruf:
\shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
Der Parameter \emph{-+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 Verzögerung zwischen den einzelnen Tests, ohne den der Benchmark fehlerhaft läuft.\\
\subsubsection{Auswertung}
@ -35,14 +35,14 @@ Die Lesegeschwindigkeit von NFS entspricht mit als Maximalwert gemessenen 109 Mi
\shellcmd{hdparm -t /dev/sda}
Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
der Leistungsfähigskeit der Festplatte entsprechen.
Die Schreibgeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
der Leistungsfähig der Festplatte entsprechen.
GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
gleich auf. Die Schreibegeschwindigkeit hingegen erreicht lediglich 28 MiB/s und
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
Schreibeoperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
Schreiboperation es etliche Kontextwechsel und Kopiervorgänge gibt, weil die
einzelnen Nodes miteinander kommunizieren müssen, um die Daten verteilt
schreiben zu können. Zusätzlich stellen hier also auch die Atom-Prozessoren
durch ihre begrenze Leistungsfähigkeit einen limitierenden Faktor dar.

4
bericht/bs/bs-git.tex
View File

@ -20,7 +20,7 @@ Nun kann die eigentliche Konfiguration per git heruntergeladen werden:
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 \emph{aufgabe2.4/gitolite-admin}.
Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
Das lctp-Repository wiederum lässt sich mit folgendem Befehl klonen:
\shellcmd{git clone git@141.76.90.104:lctp.git lctp-gruppe4}
@ -55,7 +55,7 @@ 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 sich im
\href{https://github.com/joeyh/etckeeper/blob/master/debian/cron.daily}{Git-Repository}
(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe
(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cron-Job eingerichtet (siehe
\emph{aufgabe2.4/cron.daily/etckeeper}).
\subsubsection{Logs in git}

2
bericht/bs/bs-pdsh.tex
View File

@ -9,7 +9,7 @@ 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 \emph{Pdsh} auf die
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

4
bericht/bs/bs-ssh.tex
View File

@ -5,7 +5,7 @@ Wir haben uns für \emph{OpenSSH} als SSH-Server entschieden. Diesen haben wir m
\shellcmd{pacman -S openssh}
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:
Des weiteren 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
@ -43,4 +43,4 @@ Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script
\texttt{newuser} (siehe \emph{aufgabe2.3/newuser}) gelöst. Dieses Script legt
einen neuen Benutzer an, erstellt dessen Home-Verzeichnis, generiert ein neues
Public-Private-Key-Paar für SSH und trägt den eigenen Public-Key in die
\emph{authorized\_keys} ein und ermöglich den Zugriff auf das git-Repository.
\emph{authorized\_keys} ein und ermöglicht den Zugriff auf das git-Repository.

14
bericht/bs/bs.tex
View File

@ -1,6 +1,6 @@
\section{Betriebsysteminstallation}
\section{Betriebssysteminstallation}
\subsection{Wahl des Betriebsystems}
\subsection{Wahl des Betriebssystems}
\label{sub:wahl_des_betriebsystems}
Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt. Es hat mit \emph{Systemd} ein modernes und robustes init-System. Systemd verwaltet Abhängigkeiten zwischen den verschiedenen Systemdiensten. Gestartete Dienste werden überwacht und können im Fehlerfall neu gestartet werden.
@ -31,21 +31,23 @@ Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \emph{fdisk} v
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 \emph{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 Head-Node
als auch der erste Compute-Node grundsätzlich einsatzfähig.
\subsubsection{Netzwerk-Konfiguration}
Auf dem Headnode bzw. Computenode haben wir mit \emph{netctl} die beiden
Auf dem Head-Node bzw. Compute-Node 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 \emph{iptables} das \texttt{
Auf dem Head-Node mussten wir noch mittels \emph{iptables} das \texttt{
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.).
(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Compute-Nodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
\input{bs/bs-ssh}

6
bericht/burnin.tex
View File

@ -8,12 +8,12 @@ Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir
\texttt{Munin} eingerichtet. Munit 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 Headnode haben wir den
aus einer \emph{Rddtool}-Datenbank generiert. Auf dem Head-Node haben wir den
Masterprozess installiert:
\shellcmd{pacman -S munin}
Auf dem Computenode die Nodekomponente:
Auf dem Compute-Node die Nodekomponente:
\shellcmd{pacman -S munin-node}
@ -39,7 +39,7 @@ klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe
Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche
von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme.
Auf dem Computenode haben wir folgende Plugins aktiviert:
Auf dem Compute-Node haben wir folgende Plugins aktiviert:
\begin{itemize}
\item cpu

2
bericht/cluster-layout.tex
View File

@ -33,7 +33,7 @@ Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
{\bf Compute-Nodes:} \\
\begin{tabularx}{45em}{l|X|X|X|X}
Hostnames & \texttt{zotac1}\footnote{330er Board und 1. Computenode} & \texttt{zotac2} & \texttt{zotac3} & \texttt{zotac4} \\
Hostnames & \texttt{zotac1}\footnote{330er Board und 1. Compute-Node} & \texttt{zotac2} & \texttt{zotac3} & \texttt{zotac4} \\
\hline
Interne IPs & \texttt{\small 10.20.0.101} & \texttt{\small 10.20.0.102} & \texttt{\small 10.20.0.103} & \texttt{\small 10.20.0.104} \\
\hline

2
bericht/hardware.tex
View File

@ -12,7 +12,7 @@ In die beiden zur Verfügung stehenden Gehäuse bauten wir jeweils zwei Mainboar
Da nur drei ZOTAC-Boards vorhanden waren, mussten wir als vierten Compute-Node
ein normales Intel-Mainboard (ohne nVidia-Chip) verwenden. \\
Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Computenode}
Beide Boards waren jeweils ausgestattet mit: %\footnote{330er Board und 1. Compute-Node}
\begin{itemize}
\item einem (bereits fest verbautem) Intel Atom 330 Prozessor

9
bericht/ori/ori-inst.tex
View File

@ -2,7 +2,14 @@
\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 Computenode 2 ü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 beiden Coputenodes gewährleistet.
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 Compute-Nodes 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 Compute-Node 1 die
ssh-Schlüssel erstellt und anschließend auf Compute-Node 2 ü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 beiden Coputenodes gewährleistet.
\subsubsection{Installation}

2
bericht/prov/prov-backup.tex
View File

@ -4,7 +4,7 @@
Wir haben uns für \href{http://www.rsnapshot.org/}{Rsnapshot} aus folgenden Gründen entschieden:
\begin{itemize}
\item Die Backups liegen als Ordner mit den gleichen Rechten wie im zu backupenden System.
\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
selbständig Dateien wiederherstellen können.
\item Rsnapshot erstellt differentielle Backups. Dabei werden Dateien, die

14
bericht/prov/prov-provisioning.tex
View File

@ -12,14 +12,14 @@ da auf den Festplatten der Compute-Nodes genügend Speicher für das
Betriebssystem vorhanden ist und bei jedem Zugriff auf das Dateisystem unnötigen
Latenzen entstehen würden.
Um Clonezilla auf den Computenodes zu booten, haben wir den
Um Clonezilla auf den Compute-Nodes 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 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 Computenodes verwaltet werden können. Mit
Außerdem haben wir ein Script \emph{ cluster} geschrieben, mit dem die Compute-Nodes verwaltet werden können. Mit
\begin{lstlisting}
cluster add <HOSTNAME> <IP> <MAC>
\end{lstlisting}
@ -42,22 +42,22 @@ Konfigurationsdateien liegen in \emph{/srv/tftp/pxelinux/pxelinux.cfg}.
\end{sloppypar}
\subsubsection{Provisionierung der Computenodes}
\subsubsection{Provisionierung der Compute-Nodes}
\begin{sloppypar}
Um den Clone-Vorgang zu starten, führten wir nun mit dem Befehl \emph{sudo
cluster set-clone <HOSTNAME>} aus. Durch Neustart des Nodes wird das Clonezilla
Live Image gebootet. Dieses holt sich nun vom Headnode ein Script und führt es
Live Image gebootet. Dieses holt sich nun vom Head-Node ein Script und führt es
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
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.
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{
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.

3
bericht/prov/prov.tex
View File

@ -1,5 +1,4 @@
\section{Compiler, Modules, Backup und Klonen
des Compute Nodes}
\section{Compiler, Modules, Backup und Klonen des Compute-Node}
\input{prov/prov-compiler}

4
bericht/sv/sv-dhcp_dns.tex
View File

@ -5,10 +5,10 @@
\begin{sloppypar}
Wir haben uns für den \emph{ISC-Dhcpd} als DHCP-Server entschieden. Zur
Konfiguration haben wir in \emph{/etc/dhcpd.conf} (siehe \emph{aufgabe3.2}) die
interne Top-Level-Domain \emph{zotac} eintragen und den Headnode als DNS-Server eingestellt.
interne Top-Level-Domain \emph{zotac} eintragen und den Head-Node als DNS-Server eingestellt.
\end{sloppypar}
Des Weiteren haben wir das Subnet \emph{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 Head-Node als verantwortlichen Router eingetragen.
Die Pro-Host-Konfiguration sieht bei uns wie folgt aus:

10
bericht/sv/sv-filesystems.tex
View File

@ -25,8 +25,8 @@ Elastic-Hashing nennt. Dieser verteilte Ansatz verbessert die Verfügbar- und
Skalierbarkeit, da bei Dateisystemen wie Lustre, der Metadatenserver häufig zum
Flaschenhals wird. Das Dateisystem lässt sich im laufenden Betrieb um weitere
Nodes erweitern. GlusterFS kann auf beliebige Dateisysteme aufgesetzt werden,
was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzigste
Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von Fuse im
was die Wiederherstellung im Falle eines Absturzes vereinfacht. Der einzige
Nachteil, der uns aufgefallen ist, ist das GlusterFS auf Basis von FUSE im
User-Space implementiert ist, was potentiell langsamer als eine entsprechende
Kernel-Implementierung ist.
@ -36,7 +36,7 @@ Partition angelegt, diese mit Befehl:
\shellcmd{mkfs.xfs -i size=512 /dev/sda5}
formatiert und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab).
Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Computenode:
Nach dem Starten des GlusterFS-Dienstes, sowohl auf Head- und Compute-Node:
\shellcmd{systemctl enable glusterfs.service}
@ -60,8 +60,8 @@ Um die Schreibdurchsatz zu ermitteln, verwendeten wir den Befehl \emph{dd}:
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 die Leserate haben wir folgenden Befehl benutzt um dieselbige
erstellte Datei zu lesen:
ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um erstellte
Datei zu lesen:
\shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync}

2
bericht/sv/sv-ldap.tex
View File

@ -34,7 +34,7 @@ Um auf den Verzeichnisdienst zugreifen zu können, haben wir eine Datei
angelegt, die nur durch \emph{root}-Benutzer zugreifbar ist
(Verzeichnisberechtigung $600_8$).
\subsubsection{Client-Konfiguration (Headnode und Computenode)}
\subsubsection{Client-Konfiguration (Head-Node und Compute-Node)}
\begin{sloppypar}
Hierfür haben wir die Variablen \emph{BASE, URI, TIMEOUT, NETWORK\_TIMEOUT} in