Korrekturlesen: 1. Anlauf
This commit is contained in:
parent
9cd1f7e26b
commit
62ad17d07a
|
|
@ -34,8 +34,6 @@
|
|||
:internal - [0:0]
|
||||
-A uni -j internal
|
||||
-A internal -p tcp --dport 22 -j ACCEPT
|
||||
-A internal -p tcp --dport 80 -j ACCEPT
|
||||
-A internal -p tcp --dport 443 -j ACCEPT
|
||||
|
||||
# ---------------------------------------------------------------
|
||||
# public traffic
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
\subsection{Installation des Batchsystems}
|
||||
|
||||
Aus dem AUR (\ref{sec:aur}) installierten wir
|
||||
\href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3.
|
||||
SLURM benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst.
|
||||
\href{http://www.schedmd.com/#index}{SLURM} in der Version 2.6.3. SLURM
|
||||
benötigt für die Authentifizierung zwischen den Nodes einen externen Dienst.
|
||||
Dazu richteten wir den empfohlenen
|
||||
\href{MUNGE}{http://code.google.com/p/munge/}-Daemon ein und verteilten den auf
|
||||
\href{http://code.google.com/p/munge/}{MUNGE}-Daemon ein und verteilten den auf
|
||||
dem Head-Node erstellten Schlüssel auf die anderen Nodes
|
||||
(\emph{/etc/munge/munge.key}).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,10 @@
|
|||
\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 scheint, da selbst die SLURM-Entwickler hierzu nichts weiter sagen können:
|
||||
Wir haben uns entschieden, Maui nicht einzurichten, da SLURM bereits einen
|
||||
eigenen Scheduler mitbringt und Maui äußerst schwierig einzurichten zu sein
|
||||
scheint, so dass selbst die SLURM-Entwickler hierzu keine Dokumentation
|
||||
anbieten:
|
||||
|
||||
\epigraph{Maui configuration is quite complicated and is really beyond the scope of any documents we could supply with SLURM.}{\href{https://computing.llnl.gov/linux/slurm/maui.html}{SLURM-Website}}
|
||||
\epigraph{Maui configuration is quite complicated and is really beyond the scope
|
||||
of any documents we could supply with
|
||||
SLURM.}{\href{https://computing.llnl.gov/linux/slurm/maui.html}{SLURM-Website}}
|
||||
|
|
|
|||
|
|
@ -3,5 +3,3 @@
|
|||
\input{batch/bat-installation}
|
||||
\input{batch/bat-konfiguration}
|
||||
\input{batch/bat-maui}
|
||||
|
||||
\pagebreak
|
||||
|
|
|
|||
|
|
@ -36,6 +36,8 @@ einen Wert von {\bf 4,076 GFlops}.
|
|||
|
||||
\subsubsection{Auswertung}
|
||||
|
||||
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 damit also ca. 16 \% der maximal möglichen Leistung, was in Anbetracht des langsamen Verbindungsnetzwerkes ein akzeptabler Wert ist.
|
||||
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
|
||||
Wert ist.
|
||||
|
|
|
|||
|
|
@ -35,6 +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ähig der Festplatte entsprechen.
|
||||
Die Schreibegeschwindigkeit liegt bei maximal 62 MiB/s und sollte auch in etwa
|
||||
der Leistungsfähigskeit 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 lieg 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 etliche Kontextwechsel 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.
|
||||
GlusterFS liegt in der Lesegeschwindigkeit von maximal 104 MiB/s etwa mit NFS
|
||||
gleich auf. Die Schreibegeschwindigkeit 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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
\subsection{Git-Server}
|
||||
\label{sub:git_server}
|
||||
|
||||
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:
|
||||
Zur Verwaltung von \emph{Git} haben wir uns für
|
||||
\href{https://github.com/sitaramc/gitolite}{Gitolite} entschieden. Gitolite
|
||||
erlaubt eine Verwaltung von Zugriffsrechten auf Repositories. Die
|
||||
Authentifizierung erfolgt dabei über SSH-Keys. Hier für wird ein Nutzer mit dem
|
||||
Namen \emph{git} eingerichtet:
|
||||
|
||||
\shellcmd{useradd -m -U -r -s /bin/bash -d /srv/git git}
|
||||
|
||||
|
|
@ -23,46 +26,48 @@ Das lctp-Repository wiederum lässt sich mit folgendem Befehl clonen:
|
|||
|
||||
\shellcmd{cd lctp-gruppe4 \&\& git submodule init \&\& git submodule update}
|
||||
|
||||
\subsubsection{etckeeper}
|
||||
\subsubsection{Etckeeper}
|
||||
|
||||
Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu machen installierten wir \emph{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 \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, \texttt{
|
||||
etckeeper} in ein dediziertes Repository (\emph{logs}) pushen und als Submodule
|
||||
im \emph{lctp}-Repository einzubinden:
|
||||
Etckeeper 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, \texttt{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 \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 \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 \texttt{
|
||||
/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
|
||||
Im Gegensatz zu 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 ein
|
||||
\href{https://gist.github.com/Mic92/7250403}{Wrapper-Script} für \emph{Pacman}
|
||||
und \emph{Yaourt} geschrieben und beide in den Pfad \emph{/usr/local/bin}
|
||||
abgelegt. Da in der Shell \emph{/usr/local/bin} für gewöhnlich eine höhere
|
||||
Priorität besitzt als \texttt{/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 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 installiert (siehe
|
||||
(Stand 07.11.2013) von \emph{etckeeper} liegt, als Cronjob eingerichtet (siehe
|
||||
\emph{aufgabe2.4/cron.daily/etckeeper}).
|
||||
|
||||
\subsubsection{Logs in git}
|
||||
|
||||
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 \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 \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 \emph{logs} im
|
||||
Archlinux setzt in der Standard-Installation \emph{Journald} als Logging-Daemon
|
||||
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
|
||||
\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
|
||||
lctp-Repository eingebunden.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,19 @@
|
|||
\subsection{Parallel Distributed Shell (PDSH)}
|
||||
\label{sub:parallel_shell}
|
||||
|
||||
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.
|
||||
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 \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 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}).
|
||||
\subsubsection{Gruppenverwaltung} Zur Verwaltung mehrerer Rechner in Gruppen (in
|
||||
unserem Fall Headnode und Computenodes) 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
|
||||
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}).
|
||||
|
|
|
|||
|
|
@ -16,14 +16,31 @@ ChallengeResponseAuthentication no
|
|||
\subsubsection{iptables}
|
||||
|
||||
Um den Zugriff auf das universitätsinterne Netz zu beschränken wurde ein
|
||||
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.
|
||||
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
|
||||
den SSH-Port 22 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 \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.
|
||||
Um den Zugriff aus einem externen Netz abzusichern, gibt es verschiedene
|
||||
Möglichkeiten
|
||||
|
||||
\begin{enumerate}
|
||||
\item den externen SSH-Port auf einen anderen Port als 22 legen, so dass
|
||||
dieser nicht zu leicht erraten werden kann
|
||||
\item per \emph{Fail2ban} IPs, die z.B. per
|
||||
Bruteforce zu häufig versuchen sich einzuloggen, aussperren
|
||||
\item den externen SSH-Port 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
|
||||
\item den Login auf bestimmte Benutzer begrenzen
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{Automatisierung für neue Nutzer}
|
||||
|
||||
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 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.
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -5,14 +5,25 @@
|
|||
|
||||
Wir haben \href{http://www.archlinux.org/}{Arch Linux} als Betriebssystem gewählt.
|
||||
|
||||
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.
|
||||
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.
|
||||
Das Logging delegiert \emph{Systemd} an \emph{Journald}. Journald 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.
|
||||
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 Pakete 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.
|
||||
|
||||
Ist diese nicht im offiziellen Repository vorhanden, so kann man viele weitere Pakete im AUR finden (siehe ~\ref{sec:aur}). Im Unterschied zum offiziellen Repository werden Pakete aus dem AUR aus den Quellen gebaut. Das einfach gehaltene Buildsystem, erlaubt es schnell in den Paketbau einzugreifen werden und eigene Varianten eines Paketes zu bauen.
|
||||
Neben dem offiziellen Repository gibt es viele weitere Pakete im AUR (siehe
|
||||
~\ref{sec:aur}). Im Unterschied zum offiziellen Repository werden Pakete im AUR
|
||||
aus den Quellen gebaut. Das einfach gehaltene Buildsystem erlaubt es, schnell in
|
||||
den Paketbau einzugreifen zu können und eigene Varianten eines Paketes zu bauen.
|
||||
|
||||
Als Nachteile muss man hingegen aufführen, dass es leider keinen kommerziellen Support gibt. Dies wäre für größere Installationen notwendig. Außerdem muss bei den Systemupdates darauf achten werden, dass eine neue Version eines Paketes noch mit der aktuellen (möglicherweise geänderten) Konfiguration kompatibel ist.
|
||||
Als Nachteile muss man hingegen aufführen, dass es leider keinen kommerziellen
|
||||
Support gibt, welcher für größere Installationen notwendig wäre. Außerdem muss
|
||||
bei den Systemupdates darauf achten werden, das eine neue Version eines Paketes
|
||||
noch mit der aktuellen (möglicherweise geänderten) Konfiguration kompatibel ist.
|
||||
|
||||
\subsection{Installation}
|
||||
|
||||
|
|
|
|||
|
|
@ -4,43 +4,42 @@
|
|||
\subsection{Munin}
|
||||
\label{sub:munin}
|
||||
|
||||
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir \texttt{
|
||||
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
|
||||
\emph{rddtool}-Datenbank generiert. Auf dem Headnode haben wir den Masterprozess
|
||||
installiert:
|
||||
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
|
||||
Masterprozess installiert:
|
||||
|
||||
\shellcmd{pacman -S munin}
|
||||
|
||||
|
||||
Auf dem Computenode die Nodekomponente:
|
||||
|
||||
\shellcmd{pacman -S munin-node}
|
||||
|
||||
Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{nginx} ein:
|
||||
Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{Nginx} ein:
|
||||
|
||||
\shellcmd{pacman -S nginx}
|
||||
|
||||
Dieser kommuniziert über fastcgi mit Munin um die Graphen
|
||||
generieren zu lassen. Die nötige Konfiguration befindet sich in \texttt{
|
||||
aufgabe2.5/nginx}. Die fastcgi-Prozesse von Munin starteten wir mit folgenden
|
||||
Der Webserver kommuniziert über das FastCGI-Protokoll mit Munin um die Graphen
|
||||
generieren zu lassen. Die nötige Konfiguration befindet sich in
|
||||
\texttt{aufgabe2.5/nginx}. Den FastCGI-Prozess von Munin starteten wir mit dem
|
||||
Befehl:
|
||||
|
||||
\shellcmd{systemctl enable munin-graph.socket munin-html.socket}
|
||||
|
||||
\shellcmd{systemctl start munin-graph.socket munin-html.socket}
|
||||
|
||||
Die ab zu fragenden Nodes werden in die \emph{munin.conf} eingetragen (\texttt{
|
||||
aufgabe2.6/munin.conf}).
|
||||
Da die Anzahl unserer Nodes verhältnismäßig klein ist, haben wir uns für die
|
||||
Aktualisierung der Leistungsdaten via \emph{munin-cron} entschieden:
|
||||
Die abzufragenden Nodes werden in die \emph{munin.conf} eingetragen
|
||||
(\texttt{aufgabe2.6/munin.conf}). Da die Anzahl unserer Nodes verhältnismäßig
|
||||
klein ist, haben wir uns für die Aktualisierung der Leistungsdaten mithilfe
|
||||
\emph{munin-cron} entschieden:
|
||||
|
||||
\shellcmd{crontab /etc/munin/munin-cron-entry -u munin}
|
||||
|
||||
Munin bringt bei der Installation schon eine Vielzahl von Plugins mit. Manche
|
||||
von diesen benötigen wiederum für die Datenerfassung andere Programme. Auf dem
|
||||
Computenode haben wir folgende Plugins aktiviert:
|
||||
von dieser Plugins benötigen wiederum für die Datenerfassung andere Programme.
|
||||
Auf dem Computenode haben wir folgende Plugins aktiviert:
|
||||
|
||||
\begin{itemize}
|
||||
\item cpu
|
||||
|
|
@ -51,7 +50,8 @@ Computenode haben wir folgende Plugins aktiviert:
|
|||
\item sensors\_temp
|
||||
\end{itemize}
|
||||
|
||||
Zum Belasten des Systems über 48h verwendeten wir \emph{stress} mit jeweils 4 Workern für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung.
|
||||
Zum Belasten des Systems über 48h verwendeten wir das Programm \emph{Stress} mit
|
||||
4 Worker-Prozessen für jeweils CPU-, IO-, Speicher- und Festplatten-Auslastung.
|
||||
|
||||
\pagebreak
|
||||
|
||||
|
|
@ -90,7 +90,8 @@ Abschließend ist zu sagen, dass der Compute-Node den Burnin ohne nennenswerte A
|
|||
|
||||
\subsubsection{Shutdown}
|
||||
|
||||
Nach dem Burnin sollte der Compute-Node automatisch heruntergefahren werden. Dazu nutzten wir folgenden Shell-Befehl:
|
||||
Nach dem Burnin sollte der Compute-Node automatisch heruntergefahren werden.
|
||||
Dazu nutzten wir den Zeitparameter des \emph{Shutdown-Befehls}:
|
||||
|
||||
\shellcmd{shutdown -P 2880}
|
||||
|
||||
|
|
|
|||
|
|
@ -458,7 +458,7 @@ werden können. Allerdings ist anzunehmen, dass die Zahl architekturbedingt unte
|
|||
der von Chef liegt.
|
||||
|
||||
Zu den von offiziell von Chef unterstützt Plattformen gehören Windows, MacOS X,
|
||||
verschiedene Linuxderivate (Debian, Ubuntu, Redhat...) und Solaris. Puppet
|
||||
verschiedene Linuxderivate (Debian, Ubuntu, Redhat\ldots) und Solaris. Puppet
|
||||
bietet breiteren Support und unterstützt zusätzlich Free- und OpenBSD sowie
|
||||
HP-UX und AIX.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Jedes Board war jeweils ausgestattet mit: %\footnote{330er Board und 1. Computen
|
|||
\item einem (bereits fest verbautem) Intel Atom 330 Prozessor
|
||||
\item 2 GiB DDR2-RAM
|
||||
\item 250 GiB Festplatte
|
||||
\item einem im Gehäuse bereits vorhandenes Netzteil.
|
||||
\item ein im Gehäuse bereits vorhandenes Netzteil.
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.5cm}
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
\subsection{Backup}
|
||||
\label{sub:backup}
|
||||
|
||||
Wir haben uns für rsnapshot aus folgenden Gründen entschieden:
|
||||
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.
|
||||
|
|
@ -15,18 +15,18 @@ Wir haben uns für rsnapshot aus folgenden Gründen entschieden:
|
|||
werden. Dies kann zeitaufwändig sein und ist fehleranfällig, sollte ein Delta
|
||||
beschädigt werden. Um dem entgegen zu wirken, werden deswegen in
|
||||
regelmäßigen Abständen volle Backups erstellt, was wiederum mehr
|
||||
Speicherplatz benötig.
|
||||
Speicherplatz benötigt.
|
||||
\end{itemize}
|
||||
|
||||
Die Konfigurationsdatei (/etc/rsnapshot.conf) für rsnaphot liegt in
|
||||
Die Konfigurationsdatei (/etc/rsnapshot.conf) für Rsnaphot liegt in
|
||||
\emph{aufgabe4.3/rsnaphot.conf}. Es werden folgende Verzeichnisse gesichert:
|
||||
/home/, /etc/, /usr/local/, /cluster/, /srv/, /fastfs/, /var/lib/
|
||||
|
||||
Das dafür bereitgestellte NFS ist unter \emph{/backup} gemountet. Die Backups
|
||||
werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird
|
||||
als cron-job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und
|
||||
Das dafür bereitgestellte NFS ist unter dem Pfad \emph{/backup} gemountet. Die
|
||||
Backups werden im Unterverzeichnis \emph{rsnapshot} erstellt. Das Backup wird
|
||||
als Cron-Job durch die Skripte \emph{/etc/cron.daily/rsnaphot} und
|
||||
\emph{/etc/cron.weekly/rsnapshot} durchgeführt (vgl.
|
||||
\emph{aufgabe4.3/cron.\{daily,weekly\}/rsnapshot.conf}). Dabei werden die
|
||||
letzten die Stände der letzten 7 Tage sowie die der letzten 3 Wochen
|
||||
vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und zotac1
|
||||
in \emph{/backup} erstellt.
|
||||
vorgehalten. Darüber hinaus wurde je ein vollständiges Backup von zotac0 und
|
||||
zotac1 in Verzeichnis \emph{/backup} erstellt.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
\label{sub:compiler}
|
||||
|
||||
Die benötigten Compiler/Bibliotheken für den Cluster-Betrieb wurden mit Hilfe der
|
||||
Software easybuild (\ref{sec:easybuild}) installiert.
|
||||
Software Easybuild (\ref{sec:easybuild}) installiert.
|
||||
Die installierte Software ist im Verzeichnis \emph{/cluster/} zu finden.
|
||||
|
||||
\subsubsection{GNU Compiler Collection}
|
||||
|
|
@ -15,7 +15,7 @@ Wir haben folgende GCC-Versionen installiert:
|
|||
\item \href{4.8.2-RC-20131009}{ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009/}
|
||||
\end{itemize}
|
||||
|
||||
Die für easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/GCC} zu
|
||||
Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/GCC} zu
|
||||
finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
|
||||
|
||||
\shellcmd{module swap GCC/4.8.2 GCC/4.8.1}
|
||||
|
|
@ -24,7 +24,7 @@ finden. Zwischen den Versionen kann mit folgendem Befehl gewechselt werden:
|
|||
\label{ssub:intel_compiler_suite}
|
||||
|
||||
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
|
||||
Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in \emph{aufgabe4.1/icc} zu
|
||||
finden.
|
||||
|
||||
Der C-Compiler wird mit folgenden Befehl geladen:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
\subsection{CUDA}
|
||||
\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 \emph{nvidia mesa glu libxi libmxu freeglut} installiert.
|
||||
Die für Easybuild (\ref{sec:easybuild}) benötigten Paket-Beschreibungen sind in
|
||||
\emph{aufgabe4.6} zu finden. Zusätzlich wurden die Pakete \emph{nvidia, mesa,
|
||||
glu, libxi, libmxu} und \emph{freeglut} installiert.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,12 @@
|
|||
\subsection{Modules}
|
||||
\label{sub:modules}
|
||||
|
||||
Zu Initialisierung von Modules, haben wir Shell-Skript in
|
||||
\emph{/etc/profile.d/module.sh} hinterlegt (auch zu finden in aufgabe4.2/module.sh).
|
||||
Dieses Skript fügt den Pfad \emph{/cluster/modules/all} zum MODULESPATH hinzu,
|
||||
so dass Module in diesem Verzeichnis geladen werden können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als MODULERCFILE konfiguriert.
|
||||
Diese Datei lädt Module wie den GCC-Compiler oder OpenMPI vor. Über eine
|
||||
Versionsdatei in \emph{/cluster/modules/all/GCC/.version} wird der GCC-Version 4.8.2 als default markiert. Die gesamte Modules-Konfiguration befindet sich in \emph{aufgabe4.2/modules}.
|
||||
Zu Initialisierung von Modules, haben wir das Shell-Skript in
|
||||
\emph{/etc/profile.d/module.sh} hinterlegt (auch zu finden in
|
||||
aufgabe4.2/module.sh). Dieses Skript fügt den Pfad \emph{/cluster/modules/all}
|
||||
zum MODULESPATH hinzu, so dass Module in diesem Verzeichnis geladen werden
|
||||
können. Darüber hinaus wird die Datei \emph{/cluster/modules/rc} als
|
||||
MODULERCFILE konfiguriert. Diese Datei lädt Module wie den GCC-Compiler oder
|
||||
OpenMPI vor. Über eine Versionsdatei in \emph{/cluster/modules/all/GCC/.version}
|
||||
wird der GCC-Version 4.8.2 als Standard markiert. Die gesamte
|
||||
Modules-Konfiguration befindet sich in \emph{aufgabe4.2/modules}.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,18 @@
|
|||
\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 \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:
|
||||
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 kompiliert werden:
|
||||
|
||||
\shellcmd{mpic++ hello.cpp}
|
||||
\shellcmd{mpic++ hello.cpp}
|
||||
|
||||
Mit Hilfe einer \emph{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}
|
||||
\shellcmd{mpirun \-\-hostfile hosts a.out}
|
||||
|
||||
Beispiel-Ausgabe:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,19 @@
|
|||
|
||||
\begin{sloppypar}
|
||||
|
||||
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.
|
||||
Für die Provisionierung wurde Clonezilla verwendet. Wir haben uns für dieses
|
||||
Verfahren entschieden. Bei einem Netzwerk-Boot beispielsweise, bei dem das
|
||||
gesamte Dateisystem per NFS eingebunden wird, wäre in unserem Fall ineffektiv,
|
||||
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 \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.
|
||||
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 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
|
||||
\begin{lstlisting}
|
||||
|
|
@ -17,9 +27,18 @@ 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 \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.
|
||||
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
|
||||
laden nach Boot) gewechselt werden.
|
||||
|
||||
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}.
|
||||
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 +46,38 @@ Um den Netzwerk-Boot zu ermöglichen, haben wir \emph{ pxelinux} unter \emph{ /s
|
|||
|
||||
\begin{sloppypar}
|
||||
|
||||
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.
|
||||
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
|
||||
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 \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.
|
||||
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 \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 Clonezilla bei uns das Dateisystemformat \emph{ext4} nicht als solches
|
||||
erkannt hat. Es 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 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.
|
||||
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 Befehl
|
||||
\emph{mkinitcpio -p linux} ein neue Init-Ramdisk erstellen lassen, welches die
|
||||
entsprechenden Treiber für Bootvorgang enthält.
|
||||
|
||||
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.
|
||||
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
|
||||
dem neuen Schema enpXsY sondern fest den Namen eth0 erhalten.
|
||||
|
||||
\end{sloppypar}
|
||||
\end{sloppypar}
|
||||
|
|
|
|||
|
|
@ -12,5 +12,3 @@ des Compute Nodes}
|
|||
\input{prov/prov-mpi}
|
||||
|
||||
\input{prov/prov-cuda}
|
||||
|
||||
\pagebreak
|
||||
|
|
|
|||
|
|
@ -3,7 +3,9 @@
|
|||
\subsubsection{Server}
|
||||
|
||||
\begin{sloppypar}
|
||||
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.
|
||||
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.
|
||||
\end{sloppypar}
|
||||
|
||||
Des Weiteren haben wir das Subnet \emph{10.20.0.0/24} deklariert und wiederum den Headnode als verantwortlichen Router eingetragen.
|
||||
|
|
@ -18,23 +20,33 @@ 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 ihren Hostnamen gesagt bekommen. (Die IP-Adresse holt sich der DHCP-Server vom lokalen DNS-Server.)
|
||||
Damit ist sichergestellt, dass die Hosts die im Cluster-Layout spezifizierte
|
||||
IP-Adresse entsprechend ihrer MAC-Adresse zugewiesen bekommen und gleichzeitig
|
||||
ihren Hostnamen mitgeteilt bekommen. Die IP-Adresse löst der DHCP-Server über
|
||||
den lokalen DNS-Server auf.
|
||||
|
||||
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})
|
||||
Zusätzlich haben wir das bereits in der Installation enthaltene
|
||||
\emph{Systemd}-Service-File entsprechend so angepasst, dass beim Starten und
|
||||
Aktivieren des Dienstes spezifiziert werden kann, auf welchem Netzwerk-Interface
|
||||
der Dienst hören soll. (siehe \emph{aufgabe3.2/dhcpd4@.service})
|
||||
|
||||
Starten kann man den Dienst nun mit:
|
||||
Gestartet wird der Dienst mit dem Befehl:
|
||||
|
||||
\shellcmd{systemctl start dhcpd4@eth1}
|
||||
|
||||
wobei \emph{eth1} das Interface ist, das am internen LAN angeschlossen ist.
|
||||
Wobei \emph{eth1} der Name des Interface ist, das am internen LAN angeschlossen ist.
|
||||
|
||||
\subsubsection{Client}
|
||||
|
||||
\begin{sloppypar}
|
||||
|
||||
Als Client verwenden wir \emph{dhcpcd}. \\
|
||||
Als Client verwenden wir \emph{Dhcpcd}.
|
||||
|
||||
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. \\
|
||||
Um den Hostnamen per DHCP zu setzen, mussten wir in
|
||||
\emph{/usr/lib/dhcpcd/dhcpcd-hooks/30-hostname} (siehe
|
||||
\emph{aufgabe3.2/30-hostname}) die Option \emph{hostname\_fqdn=false} setzen,
|
||||
so dass der Hostname (\emph{zotac<X>} an Stelle der FQDN \emph{zotac<X>.zotac})
|
||||
verwendet wird.
|
||||
|
||||
Außerdem haben wir noch die Zeile:
|
||||
\begin{center}
|
||||
|
|
@ -51,10 +63,12 @@ ersetzt, damit der bezogene Hostname automatisch persistent (\emph{/etc/hostname
|
|||
\subsection{DNS}
|
||||
\label{ssub:dns}
|
||||
|
||||
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}.
|
||||
Schließlich musste noch die /etc/resolv.conf angepasst werden, so dass der 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.
|
||||
Als DNS-Server haben wir \emph{Named} aus dem Programmpaket \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}. Schließlich
|
||||
musste noch die /etc/resolv.conf angepasst werden, so dass der 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.
|
||||
|
|
|
|||
|
|
@ -8,33 +8,35 @@ 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 \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 \emph{home}
|
||||
und \emph{cluster} in der fstab angelegt. (siehe \emph{aufgabe3.1/fstab}).
|
||||
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.
|
||||
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
|
||||
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. Dieses hat im Vergleich
|
||||
zu anderen verteilten Dateisystemen keine zentrale Metadaten-Server. Stattdessen
|
||||
setzt es auf das Elastic-Hashing. Dieser verteilte Ansatz verbessert die
|
||||
Verfügbar- und Skalierbarkeit, da bei Dateisystemen wie Lustre, der
|
||||
Metadatenserver häufigt 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 User-Space implementiert ist, was
|
||||
potentiell langsamer als eine entsprechende Kernel-Implementierung ist.
|
||||
Als Dateisystem haben wir uns für GlusterFS entschieden. Im Vergleich zu anderen
|
||||
verteilten Dateisystemen besitzt GlusterFS keine zentrale Metadaten-Server.
|
||||
Stattdessen verteilt es die Metadaten durch eine Netzwerktechnologie, die sich
|
||||
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
|
||||
User-Space implementiert ist, was potentiell langsamer als eine entsprechende
|
||||
Kernel-Implementierung ist.
|
||||
|
||||
Als Dateisystem für GlusterFS wird xfs empfohlen. Dafür haben wir mit fstab eine
|
||||
50GB Partition angelegt, diese mit folgenden Befehl formatiert.
|
||||
Als Dateisystem für GlusterFS wird XFS empfohlen. Dafür haben wir eine 50GB
|
||||
Partition angelegt, diese mit Befehl:
|
||||
|
||||
\shellcmd{mkfs.xfs -i size=512 /dev/sda5}
|
||||
|
||||
und nach \emph{/mnt/glusterfs} gemountet (siehe aufgabe3.3/fstab). Nach dem Starten des
|
||||
GlusterFS-Dienstes, sowohl auf Head- und Computenode:
|
||||
formatiert 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}
|
||||
|
||||
|
|
@ -52,15 +54,14 @@ Letztendlich mounten wir das GlusterFS mit folgenden Eintrag in der \emph{aufgab
|
|||
zotac0:/gv0 /fastfs glusterfs defaults 0 0
|
||||
\end{center}
|
||||
|
||||
Um die Schreibrate zu ermitteln, verwendeten wir den Befehl \emph{dd}:
|
||||
Um die Schreibdurchsatz 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 \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
|
||||
lesen:
|
||||
ermitteln. Für die Leserate haben wir folgenden Befehl benutzt um dieselbige
|
||||
erstellte Datei zu lesen:
|
||||
|
||||
\shellcmd{dd bs=1M count=512 if=/path/to/file of=/dev/null conv=fdatasync}
|
||||
|
||||
|
|
@ -70,8 +71,9 @@ 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 GlusterFS, dem
|
||||
Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.3/benchmark.txt}
|
||||
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}
|
||||
|
||||
\pgfplotsset{
|
||||
select row/.style={
|
||||
|
|
@ -133,8 +135,8 @@ Dateisystem in /fastfs entspricht. Die Rohdaten befinden sich in \emph{aufgabe3.
|
|||
\end{tikzpicture}
|
||||
|
||||
Das lokale Dateisystem war wie zu erwarten sowohl beim Lesen als auch beim
|
||||
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil, dieser
|
||||
Methode, ist das nur die Node selber Zugriff auf diese Daten hat und die Daten
|
||||
Schreiben das schnellste Dateisystem. Der offensichtliche Nachteil dieser
|
||||
Methode ist, dass nur die Node selber Zugriff auf diese Daten hat und die Daten
|
||||
nicht größer als der lokale Speicher werden kann.
|
||||
|
||||
Während beim Schreiben GlusterFS einen höheren Durchsatz verzeichnen konnte,
|
||||
|
|
|
|||
|
|
@ -2,14 +2,24 @@
|
|||
|
||||
\subsubsection{Grundkonfiguration}
|
||||
|
||||
\begin{sloppypar}
|
||||
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}
|
||||
|
||||
Beim Systemstart wird der Dienst \emph{iptables.service} gestartet und die
|
||||
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{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
|
||||
unautorisierte Zugriffe, trägt das Programm \emph{SSH-Guard} automatisch temporär
|
||||
eine neue DROP-Regel in die \emph{sshguard}-Chain ein. Verbindungen nach außen
|
||||
werden ungefiltert durchgelassen, weil es nicht effektiv ist, einzelne Ports zu
|
||||
sperren. Ein in das System bereits eingedrungener Angreifer könnte einfach
|
||||
Pakete auf anderen offenen Ports versenden.
|
||||
|
||||
\subsubsection{Forwarding und Masquerading}
|
||||
|
||||
Das Internet wird durch folgende Regel in der NAT-Tabelle:
|
||||
Der Zugriff auf das Internet wird durch folgende Regel in der NAT-Tabelle:
|
||||
|
||||
\begin{lstlisting}
|
||||
-A POSTROUTING -o eth0 -j MASQUERADE
|
||||
|
|
@ -32,5 +42,5 @@ Alle abgeblockten Verbindungen landen in der \emph{logging}-Chain, wo sie durch:
|
|||
-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 \emph{/var/log/iptables.log} gefunden werden.
|
||||
|
||||
geloggt werden. Die Anzahl der Meldungen wurde auf 2 Meldungen pro Minute
|
||||
limitiert. Der Log wird in der Datei \emph{/var/log/iptables.log} gespeichert.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,8 @@
|
|||
\label{sub:ldap}
|
||||
|
||||
\begin{sloppypar}
|
||||
Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als Basis-\emph{dn}:
|
||||
Wir haben uns für den OpenLDAP-Server entschieden. Dazu haben wir als
|
||||
Basis-\emph{DN} (Distinguished Name):
|
||||
\begin{center}
|
||||
\emph{dc=zotac,dc=lctp}
|
||||
\end{center} festgelegt.
|
||||
|
|
@ -14,9 +15,9 @@ die Gruppen unter
|
|||
\begin{center}
|
||||
\emph{dn: ou=groups,dc=zotac,dc=lctp}
|
||||
\end{center}
|
||||
ab. Für den Import dieser \emph{dn}s haben wir eine Datei
|
||||
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}
|
||||
verfügbaren Schemata haben wir \emph{core, cosine, inetorgperson, nis}
|
||||
eingestellt (siehe \emph{aufgabe3.5/slapd.conf}).
|
||||
|
||||
\end{sloppypar}
|
||||
|
|
@ -24,13 +25,14 @@ 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 (darf nur zur
|
||||
Authentifizierung abgerufen werden). Alle anderen Attribute dürfen von allen
|
||||
Passwort ändern, aber niemand das Passwort auslesen darf. Dieses wird nur für
|
||||
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
|
||||
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
|
||||
angelegt, die nur durch \emph{root} zugreifbar ist (\emph{chmod 600}).
|
||||
angelegt, die nur durch \emph{root}-Benutzer zugreifbar ist
|
||||
(Verzeichnisberechtigung $600_8$).
|
||||
|
||||
\subsubsection{Client-Konfiguration (Headnode und Computenode)}
|
||||
|
||||
|
|
@ -89,22 +91,33 @@ trägt den eigenen Public-Key in die \emph{authorized\_keys} ein, so dass der Be
|
|||
\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 \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}).
|
||||
gefordert) haben wir die Scripte \emph{ldap-users2ldif} (gibt auf der
|
||||
Standardausgabe die Daten im LDIF-Format aus anhand der Text-Datei),
|
||||
\emph{ldap-add-ldif} (fügt die im 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. \emph{user.txt}, die die hinzuzufügenden Benutzernamen zeilenweise enthält:
|
||||
Vorgehen um Systembenutzer zu erstellen, welche sich zeilenweise in einer Datei
|
||||
befinden (in diesem Beispiel heißt die Datei \emph{user.txt}):
|
||||
|
||||
\begin{itemize}
|
||||
\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
|
||||
\begin{itemize}
|
||||
\item erstellt eine \emph{.ldif}-Datei
|
||||
\item erstellt außerdem \emph{user.txt.passwords}, die die Benutzernamen und Passwörter zeilenweise enthält
|
||||
\item die Benutzernamen werden escaped (nur Kleinbuchstaben, Zahlen und »\_«, invalide Zeichen durch »\_« ersetzt, »\_« am Anfang und am Ende gestript)
|
||||
\item Passwörter werden zufällig erzeugt (mindestens jeweils ein Großbuchstabe, Kleinbuchstabe, Sonderzeichen und mindestens eine Zahl, zwischen 10 und 16 Zeichen lang)
|
||||
\item bereits existierende Benutzer oder doppelt vorkommende Nutzer werden mit einer Warnmeldung quittiert und ignoriert
|
||||
\end{itemize}
|
||||
|
||||
\item \emph{sudo ldap-add-ldif user.txt.ldif} \\
|
||||
fügt die \emph{.ldif}-Datei zu LDAP hinzu
|
||||
\begin{itemize}
|
||||
\item fügt die \emph{.ldif}-Datei zu LDAP hinzu
|
||||
\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)
|
||||
\begin{itemize}
|
||||
\item 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}
|
||||
\end{itemize}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\subsection{NTP}
|
||||
|
||||
Auf dem Head-Node wurde der Server \emph{time.zih.tu-dresden.de} als Zeitserver eingetragen und die folgende Zeile eingefügt:
|
||||
Auf dem Head-Node wurde der NTP-Server der TU-Dresden mit der Domain \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
|
||||
|
|
|
|||
Loading…
Reference in New Issue