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

letzte Instanzen von tt entfernt

This commit is contained in:
Jörg Thalheim 2014-03-29 21:04:42 +01:00
parent 9dd62a7b3c
commit 6cb30d2059
6 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -32,7 +32,7 @@ Um die Konfiguration in \emph{/etc } versionierbar und damit nachvollziehbar zu
\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, {\tt
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:
@ -44,7 +44,7 @@ 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 {\tt
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,

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

@ -8,7 +8,7 @@ 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 {\tt
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

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

@ -25,5 +25,5 @@ Um den Zugriff aus einem externen Netz abzusichern, könnte man z.B. den externe
\subsubsection{Automatisierung für neue Nutzer}
Das automatisierte Hinzufügen neuer Nutzer haben wir über ein Script {\tt
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.

2
bericht/bs/bs.tex
View File

@ -32,7 +32,7 @@ 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 {\tt
Auf dem Headnode 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}

8
bericht/burnin.tex
View File

@ -4,7 +4,7 @@
\subsection{Munin}
\label{sub:munin}
Zur Überwachung und Aufzeichnung des Systems während des Burnin haben wir {\tt
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
@ -23,7 +23,7 @@ Für das Webfrontend richteten wir darüber hinaus den Webserver \emph{nginx} ei
\shellcmd{pacman -S nginx}
Dieser kommuniziert über fastcgi mit Munin um die Graphen
generieren zu lassen. Die nötige Konfiguration befindet sich in {\tt
generieren zu lassen. Die nötige Konfiguration befindet sich in \texttt{
aufgabe2.5/nginx}. Die fastcgi-Prozesse von Munin starteten wir mit folgenden
Befehl:
@ -31,7 +31,7 @@ Befehl:
\shellcmd{systemctl start munin-graph.socket munin-html.socket}
Die ab zu fragenden Nodes werden in die \emph{munin.conf} eingetragen ({\tt
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:
@ -94,4 +94,4 @@ Nach dem Burnin sollte der Compute-Node automatisch heruntergefahren werden. Daz
\shellcmd{shutdown -P 2880}
\pagebreak
\pagebreak

30
bericht/cluster-layout.tex
View File

@ -9,18 +9,18 @@ Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
{\bf Head-Nodes:} \\
\begin{tabularx}{\textwidth}{l|X}
Hostnames & \tt zotac0 \\
Hostnames & \texttt{zotac0} \\
\hline
Interne IP & \tt 10.20.0.1 \\
Externe IP & \tt 142.76.90.104 \\
Interne IP & \texttt{10.20.0.1} \\
Externe IP & \texttt{142.76.90.104} \\
\hline
Partitionierung &
\multicolumn{1}{l}{\begin{tabularx}{\textwidth}{l r l}
\tt / & 50 GiB & Wurzelverzeichnis \\
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
\tt /home & 40 GiB & Benutzer-Verzeichnisse \\
\tt /cluster & 150 GiB & Cluster-Daten \\
\tt swap & 2 GiB & Auslagerungsspeicher \\
\texttt{/ }& 50 GiB & Wurzelverzeichnis \\
\texttt{/boot }& 1 GiB & Boot-Dateien (Kernel, \texttt{initrd}, grub, etc.) \\
\texttt{/home }& 40 GiB & Benutzer-Verzeichnisse \\
\texttt{/cluster}& 150 GiB & Cluster-Daten \\
\texttt{swap }& 2 GiB & Auslagerungsspeicher \\
\end{tabularx}} \\
\hline
NFS-Freigaben &
@ -33,22 +33,22 @@ Wir haben uns folgendes Cluster-Layout überlegt: (Details auf nächster Seite)
{\bf Compute-Nodes:} \\
\begin{tabularx}{45em}{l|X|X|X|X}
Hostnames & \tt zotac1\footnote{330er Board und 1. Computenode} & \tt zotac2 & \tt zotac3 & \tt zotac4 \\
Hostnames & \texttt{zotac1}\footnote{330er Board und 1. Computenode} & \texttt{zotac2} & \texttt{zotac3} & \texttt{zotac4} \\
\hline
Interne IPs & \tt \small 10.20.0.101 & \tt \small 10.20.0.102 & \tt \small 10.20.0.103 & \tt \small 10.20.0.104 \\
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
Partitionierung & \multicolumn{4}{l}{
\begin{tabularx}{\textwidth}{l r l}
\tt / & 100 GiB & Wurzelverzeichnis \\
\tt /boot & 1 GiB & Boot-Dateien (Kernel, {\tt initrd}, grub, etc.) \\
\tt swap & 2 GiB & Auslagerungsspeicher \\
\tt ? & 130 GiB & Reserviert
\texttt{/ }& 100 GiB & Wurzelverzeichnis \\
\texttt{/boot}& 1 GiB & Boot-Dateien (Kernel, \texttt{initrd}, grub, etc.) \\
\texttt{swap }& 2 GiB & Auslagerungsspeicher \\
\texttt{? }& 130 GiB & Reserviert
\end{tabularx}
}
\end{tabularx} \\\\\\
Wir haben uns für ein Subnetz im Privat-Class A-Netz entschieden.
Die internen IP-Adressen sollen hier aus dem {\tt 10.20.0.0/24}-Netz stammen.
Die internen IP-Adressen sollen hier aus dem \texttt{10.20.0.0/24}-Netz stammen.
Der Vorteil ist die einfache Erweiterung um weitere Subnetze.
\pagebreak