Es hat mit {\tt 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 {\tt systemd} an {\tt journald}. Dieses 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.
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.
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.
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 {\tt fdisk} vorgenommen und die Daten-Partitionen jeweils mit {\tt mkfs.ext4} auf {\tt ext4} formatiert. Hier sollte man nicht vergessen, die Boot-Partition in {\tt fdisk} auch als {\tt 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 {\tt pacstrap} installieren und danach mittels {\tt 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 {\tt GRUB} installiert und konfiguriert.
Nach dem erfolgreichen Reboot haben wir dann das Netzwerk auf eine statische IP-Adresse mittels {\tt netctl} konfiguriert. Damit waren sowohl die Headnode als auch der erste Computenode grundsätzlich einsatzfähig.
Auf dem Headnode bzw. Computenode haben wir mit {\tt netctl} die beiden
Netzwerk-Interfaces {\tt eth0} und {\tt eth1} bzw. {\tt 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 {\tt iptables} das {\tt
MASQUERADE}-Target in der {\tt POSTROUTING}-Chain in der {\tt nat}-Tabelle auf
dem {\tt eth0}-Interface setzen (siehe \emph{aufgabe2.3/iptables.rules}) und mit
{\tt sysctl} (\emph{/etc/sysctl.d}) die Option {\tt 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.).
