59 lines
3.6 KiB
TeX
59 lines
3.6 KiB
TeX
\section{Betriebsysteminstallation}
|
|
|
|
\subsection{Wahl des Betriebsystems}
|
|
\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.
|
|
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 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.
|
|
|
|
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, 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}
|
|
|
|
Wir sind bei der Installation grundlegend nach der Anleitung im \href{https://wiki.archlinux.org/index.php/Beginners'_Guide}{Arch Linux Wiki} vorgegangen.
|
|
|
|
Die Partitionierung haben wir wie im Cluster-Layout angegeben mit \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 dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels \emph{netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig.
|
|
|
|
\subsubsection{Netzwerk-Konfiguration}
|
|
|
|
Auf dem Headnode bzw. Computenode haben wir mit \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{
|
|
MASQUERADE}-Target in der \emph{POSTROUTING}-Chain in der \emph{nat}-Tabelle auf
|
|
dem \emph{eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
|
|
\emph{sysctl} (\emph{/etc/sysctl.d}) die Option \emph{net.ipv4.ip\_forward = 1}
|
|
(siehe \emph{aufgabe2.2/10-ip-forward-conf}) freischalten, damit die Computenodes auch auf das Internet zugreifen können (Paketinstallationen, Updates, etc.).
|
|
|
|
\input{bs/bs-ssh}
|
|
|
|
\input{bs/bs-git}
|
|
|
|
\input{bs/bs-pdsh}
|
|
|
|
\pagebreak
|